Following tradition…

As it has become tradition with all developer blogs, the first article shall be a technical description of the blog itself.

Have you heard of HTMX?

Yes, this is a Go + HTMX website (with Templ). How original? Especially considering that as of writing this article, HTMX has become quite notorious and divisive in the Web-Dev world.

In my defense I must say I’ve been playing around with self-built tools somewhat like HTMX before I had learned of its existence in 2021, “before it became popular”. But I digress.

I will get around to writing an article about my first experiences (re)learning Web-Dev in 2018. Eventually. But for now, I will summarize my stance on modern Front-End Web-Dev.
“How did we get here”. An environment based on an interpreted language that requires at least a transpiler and, a bundler to get started… Need I say more?

As it’s become obvious by my rhetoric (and choice of stack), I like to keep things simple. It may not be the easiest way (although it often is). It may not be the most efficient way. But I can wrap my brain around it and I can keep a larger functional context of my projects in my head. I like that. It makes me productive. I think more about what my code does and less how my code does.

The stack

Since I’ve decided to go for HTMX for my Front-End, it makes sense to pick a language with good templating libraries. Golang is an obvious choice. The built-in templating module is part of the standard, and it even implements HTML. Even more conveniently, a third-party library Templ extends the functionality of the existing templating tools with some neat syntactic sugar.

The styles are just PicoCSS served from /public as a static asset.
I’m primarily a BE dev. Don’t judge me!

Finally, the HTTP server. Golang has no shortage, but I’ve gone for Echo. No particular reason, it was the first one I saw…
To be fair and give credit where it’s due Echo’s docs were very clear, simple and straightforward, so I never felt like I needed to look for something else.

I appreciate this stack is an overkill for a project with such a narrow scope. But I get a feel for these tools as I’m planning on building a larger project which I will talk about once it takes shape.

The articles

All of these articles are just MD files. The Go Back End is responsible for translating the MD files into HTML. This means anyone can plop the Go binary into their server env of choice, follow the folder structure for articles in my README and they can have their own version of this blog.

A nice little extra is that the articles, and the code itself, are separate repos. That way I can keep articles version control separate from the functional side.

I’m aware that I can pre-process the MD files into HTML files via a “build” step and inject them into the page instead of doing the conversion for every request. But I didn’t feel it necessary. And frankly not very interested in doing it either.

“This sounds like an SSG with extra steps” you ask? Well… You are right…

Breaking tradition

Sure, I can just use something like Hugo or Gatsby (god forbid even Wordpress). Many do. But what’s the fun in that?

This notion that reinventing the wheel is pointless or that “making custom tools and libraries when off the self solutions exist is a waste of time” baffles me. Especially if this is a personal project.

You probably won’t create a better Godot or UE. But that doesn’t mean you shouldn’t try to write your own game engine.
Likely a lot of the articles you’ll find here will be reflections on me reinventing wheels or opinions on my experience using custom stacks/tools versus well established ones.

Often the best way to way to understand how the wheel works and how best to use it is to try to reinvent it first.